home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1993 / Internet Info CD-ROM (Walnut Creek) (1993).iso / inet / internet-drafts / draft-ietf-stif-paging-protocol-00.txt < prev    next >
Text File  |  1993-08-24  |  10KB  |  225 lines
  1.  
  2. Network Working Group                           Allen Gwinn
  3. Internet Draft <STIF>                 Southern Methodist University
  4. Expiration:  3/94                         23 August 1993
  5.                                
  6.                                
  7.                                
  8.  
  9.            SIMPLE NETWORK PAGING PROTOCOL - VERSION 1
  10.  
  11.  
  12. Status of this Memo
  13.  
  14.   This document is an Internet Draft.  Internet Drafts are
  15.   working documents of the Internet Engineering Task Force
  16.   (IETF), its Areas, and its Working Groups.  Note that other
  17.   groups may also distribute working documents as Internet
  18.   Drafts. Internet Drafts are draft documents valid for a
  19.   maximum of six months.   Internet Drafts may be updated,
  20.   replaced, or obsoleted by other documents at any time.  It is
  21.   not appropriate to use Internet Drafts as reference material
  22.   or to cite them other than as a "working draft" or "work in
  23.   progress." Please check the I-D abstract listing contained in
  24.   each Internet Draft directory to learn the current status of
  25.   this or any other Internet Draft.
  26.  
  27.   It is intended that this document will be submitted to the
  28.   IESG for consideration as a standards document.  Distribution
  29.   of this document is unlimited.
  30.   
  31.  
  32.  
  33.  
  34. Introduction
  35.  
  36.   Beepers are as much a part of computer nerdom as X-terminals (perhaps,
  37.   unfortunately, more).  The intent of Simple Network Paging Protocol is
  38.   to provide a standard whereby pages can be delivered to individual
  39.   paging terminals.  The most obvious benefit is the elimination of the
  40.   need for modems to produce alphanumeric pages, and the added ease of
  41.   delivery of pages to terminals in other cities or countries.
  42.   Additionally, automatic page delivery should be somewhat more
  43.   simplified.
  44.  
  45. System Philosophy
  46.  
  47.   Radio paging is somewhat taken for granted, because of the wide
  48.   availability and wide use of paging products.  However, the actual
  49.   delivery of the page, and the process used (especially in wider area
  50.   paging) is somewhat complicated.  When a user initiates a page, by
  51.   dialing a number on a telephone, or entering an alphanumeric page
  52.   through some input device, the page must ultimately be delivered to
  53.   some paging terminal, somewhere.  In most cases, this delivery is made
  54.   using TAP (Telocator Alphanumeric input Protocol, also known as IXO).
  55.   This protocol can be a somewhat convoluted, and complicated protocol
  56.   using older style ASCII control characters and a non-standard
  57.   checksumming routine to assist in validating the data.  One note: even
  58.   though the TAP protocol allows for a password for sending simple
  59.   pages, they are rarely used (especially in commercial markets), and
  60.   therefore support for them has not been implemented in this version of
  61.   the protocol.
  62.   
  63.   Even though TAP is widely used throughout the industry, there are
  64.   plans on the table to move to a more flexible "standard" protocol (the
  65.   proposal for which is actually more convoluted than most Internet
  66.   RFC's).  However, acknowledging the complexity and flexibility of the
  67.   current protocols (or the lack thereof), the final user function is
  68.   quite simple: to deliver a page from point-of-origin to someone's
  69.   beeper.  That is the simple function that this protocol attempts to
  70.   address.
  71.  
  72. The Protocol
  73.  
  74.   The SNPP protocol is a sequence of commands and replies, and is based
  75.   on the philosophy of many other Internet protocols currently in use.
  76.   SNPP has six input commands (the first 4 characters of each are
  77.   significant) that solicit various server responses falling into three
  78.   categories: (1)successful, (2)failed-but-continue, and (3)failed-with-
  79.   connection-terminated.  The first character of every server response
  80.   is a single character indicating the category of response: '+', '!',
  81.   and '-' respectfully.
  82.   
  83.   The session interaction is actually quite simple (hence the name).
  84.   The client initiates the connection with the listening server.  Upon
  85.   opening the connection, the server issues a greeting followed by
  86.   "+READY" (indicating the willingness of the server to accept SNPP
  87.   commands).  The client passes pager ID information, and a message,
  88.   then issues a "SEND" command.  The server then feeds the information
  89.   to the TAP paging terminal, gathers a response, and reports the
  90.   success or failure to the client.
  91.  
  92. A Typical Successful Connection
  93.  
  94.       Client                           Server
  95.   
  96.   
  97.   Wait for Connection
  98.   Open Connection            -->
  99.                                <-- SNPP Gateway (Version Foo.Bar)
  100.                                    Copyright Gwinn, Bletchley and Foo
  101.                                    +READY
  102.   PAGE 5551212               -->
  103.                                <-- +OK
  104.   MESS Your network is hosed -->
  105.                                <-- +OK
  106.   SEND                       -->
  107.                                <-- +Page Sent
  108.   QUIT                       -->
  109.                                 <-- +OK, Goodbye
  110.  
  111. Commands
  112.  
  113.   PAGEr <Pager ID>
  114.  
  115.      The PAGEr command sets the pager ID (PID) number, for the
  116.      transaction, into the gateway.  The PID used must reside in the TAP
  117.      terminal (and there is where it should be validated).  Limited
  118.      validation may optionally be done on the server (such as all
  119.      numeric, and ID length), or it can all be done by the TAP terminal
  120.      at the time the page is sent.  Duplicating the PAGEr command before
  121.      SENDing the message should produce an "!ERROR, Already Entered"
  122.      message, and allow the user to continue.
  123.  
  124.   MESSage <Alpha or Numeric Message>
  125.  
  126.      The MESSage command sets the numeric or alphanumeric message for
  127.      the transaction, into the gateway.  Limited validation of the
  128.      message may be done on the SNPP server (such as length), but type-
  129.      of-message validation should be done on the TAP terminal.
  130.      Duplicating the MESSage command before SENDing the message should
  131.      produce an "!ERROR, Already Entered" message, and allow the user to
  132.      continue.
  133.  
  134.   RESEt
  135.  
  136.      The RESEt command clears the PAGEr and MESSage fields, and allows
  137.      the client to start over.  This is provided, primarily, as a means
  138.      to reset accidentally entered information during a manual session.
  139.      Upon a successful reset, the server should respond "+RESET OK".
  140.  
  141.   SEND
  142.  
  143.      The SEND command processes the page to the TAP terminal.  Prior to
  144.      processing, the PAGEr and MESSage fields should be checked for the
  145.      existence of information.  Should one of these required fields be
  146.      missing, the server should respond "!Error, Incomplete Information"
  147.      and allow the user to continue.  Assuming all of the fields are
  148.      filled in, the SNPP server should format and send the page to the
  149.      TAP terminal, and await a response.  Upon receiving a reply, the
  150.      server should respond as follows:
  151.  
  152.        +Page Sent     - Indicates successful delivery
  153.        -Error, <reason>     - Indicates unsuccessful, and gives a reason
  154.      
  155.      After processing a SEND command, the server should remain online to
  156.      allow the client to enter another page.
  157.  
  158.   QUIT
  159.  
  160.      The QUIT command terminates the current session.  The server should
  161.      respond "+OK, Goodbye" and close the connection.
  162.      
  163.   HELP
  164.      
  165.      The HELP command (optional) displays a screen of information about
  166.      commands that are valid on the SNPP server.  This is primarily to
  167.      assist manual users of the gateway.
  168.  
  169. Illegal Commands
  170.  
  171.   Should the client issue an illegal command, the server should respond
  172.   "-ERROR, Goodbye" and close the connection immediately.
  173.  
  174. Timeouts
  175.  
  176.   The SNPP server can, optionally, have an inactivity timeout
  177.   implemented.  At the expiration of the allotted time, the server
  178.   responds "-ERROR, Timeout" and closes the connection.
  179.  
  180. Rigidity of Command Structure
  181.  
  182.   The commands from client to server should remain constant.  However,
  183.   since the first character of the response indicates success or
  184.   failure, the text of the server responses could be altered should one
  185.   desire.  The following is a hunk of C code that is used currently in
  186.   an SNPP gateway.  The only response that has not been discussed is "-
  187.   SERVER DOWN, Goodbye" and is used when the gateway is administratively
  188.   down, or when there are communication problems with the TAP terminal.
  189.  
  190.      /* SNPP Client Commands */
  191.      
  192.      #define PAGER    "PAGE"
  193.      #define MESSAGE  "MESS"
  194.      #define SEND     "SEND"
  195.      #define QUIT     "QUIT"
  196.      #define RESET    "RESE"
  197.      #define HELP     "HELP"
  198.      
  199.      /* Responses from SNPP server to client */
  200.      
  201.      #define SNPP_READY                                         "+READY"
  202.      #define SNPP_OK  "+OK"
  203.      #define SNPP_RESET                                      "+Reset OK"
  204.      #define SNPP_SENT "+Page Sent"
  205.      #define SNPP_NOTSENT                                      "!Error,"
  206.      #define SNPP_ENTERR                       "!Error, Already Entered"
  207.      #define SNPP_ERRINC                       "!Error, Incomplete Info"
  208.      #define SNPP_OKCLOS                                  "+OK, Goodbye"
  209.      #define SNPP_TIMEOUT                              "-ERROR, Timeout"
  210.      #define SNPP_ERRCLOS                              "-ERROR, Goodbye"
  211.      #define SNPP_DOWN "-SERVER DOWN, Goodbye"
  212.      
  213. Author's Address
  214.  
  215.   R. Allen Gwinn, Jr.
  216.   Associate Director, Computing Services
  217.   Business Information Center
  218.   Southern Methodist University
  219.   Dallas, TX  75275
  220.   
  221.   Phone:                                                   214/768-3186
  222.   
  223.   Email:          allen@mail.cox.smu.edu  or  allen@sulaco.lonestar.org
  224.  
  225.